IT 形态变革下的备份恢复技术 | 周末送资料
本文是社区会员好评的高分资料，由备份专家CHX分享。
目 录
第1章 信息化基础资源架构变革
1.1 数据中心基础架构的变革
1.2 变革与发展之中的数据保护
1.3 新时期下数据保护的期待
第2章 信息化基础资源架构的新发展
2.1 OpenStack
2.2 HCI
2.3 大数据处理平台
第3章 BRS技术发展
3.1 BRS技术发展之存储容灾
3.2 BRS技术发展之备份恢复系统
3.3 核心技术详解
3.3.1 重复数据删除技术简介
3.3.2 重复数据删除技术原理解析
3.3.3 重复数据删除的期望收益
3.3.4 重复数据删除的实际运行效率
第4章 备份恢复系统的考量
4.1 备份恢复系统现状及问题
4.2 备份恢复系统的考量
4.2.1 架构规划
4.2.2 参数调优
4.2.3 系统优化
第一章 信息化基础资源架构变革
1.1 数据中心基础架构的变革
随着制造工艺的发展、技术手段的提升以及专业领域逐年丰富的经验积累，集中式存储不管从性能、规格以及解决方案的完整性上，差距日益缩小，市场份额逐年平均化，不再是一家独大的局面。同时，集中式存储市场逐步被其他方案蚕食，云计算的兴起带动了云普及，私有云、公有云以及混合云在数据中心内得到了极大程度的推广和应用，随之风生水起的分布式存储也广泛应用。在数据中心及业务系统蓬勃的发展时，企业内的海量数据的备份与保护也对存储和备份系统提出了前所未有的调整。
大数据的概念也逐步深入企业，以Hadoop为代表的大数据基础架构近些年也走进了企业数据中心。大数据分析在企业安全、业务分析以及行为趋势等方面有着得天独厚的优势，不少IT组织开始响应大数据的需求，纷纷涉足这片新兴领域。大数据基础架构以相对低廉的成本实现了对等的高效能、高性能以及可靠性，然而其架构却与传统应用架构天壤之别，备份解决方案短时间内无法充分满足各式各样的需求，同时面对大数据处理提出的性能指标面临着艰巨的调整。由于分布式的架构数据离散，不再能凭借存储的高性能进行复制一劳永逸，仅依靠副本技术又不能充分满足对大数据的保护。为了适应大数据市场，不少软件厂商正在集中资源开发新的数据保护技术。
在大数据的运用上，运营商与互联网等企业涉足较早。运营商在“行为趋势”方面运用大数据的案例已有不少，例如对用户在4G移动网络使用上的行为趋势分析，预估用户在各时段的使用的情况然后推出针对不同使用情况推出新的套餐业务等；还有各套餐业务的运营情况，将部分用户数据导入大数据系统进行分析计算，评估利益与风险点，针对分析结果来改良套餐等。除此之外，大数据在安全攻防上也有不少应用，尤其是大型互联网企业的实际投入。随着云化的理念越来越深刻，安全的重要级别也随之提升。传统的安全校验收益甚小，然而大数据系统可以根据安全逻辑、规则进行正反验算，由点及面遍历整个系统层次，有效的挖掘潜在安全攻防的盲点与潜在风险点。伴随着大数据分析带来的显著收益，数据背后彰显着的巨大价值逐步展现出来，未来对于大数据的应用会更加全面而深刻。
随着大数据兴起的另一个基础架构——超融合。超融合基础架构解决了自传统架构（如Server-Network-Storage等）以来需要花费大量人力物力来进行系统集成的棘手难题，将零散的资源与平台进行了统一整合。超融合解决方案在整合IT资源的同时，也大幅简化了信息系统的架构，资源高度集中，管理维护成本大幅降低。高度统一的平台对数据的安全与保护也提出了复杂而苛刻的挑战，由于超融合的结构特性，传统的备份解决方案难以完美契合，所以在数据备份、恢复、归档和容灾方面仍然有一段很长的路要走。
超融合对于中小型企业起步助益尤其明显，中小型企业起步初期在信息基础资源方面专业性人才贫瘠，超融合平台精简了信息架构，极大程度的降低了维护管理的成本。相对于大体量的云架构和复杂的传统架构而言，超融合在项目成本上也拥有不少优势，这使得初创企业在IT层管理上节省相当一部分资源。值得注意的是，在交互复杂的业务场景（如金融、保险等企业）中超融合的精简架构也带来了一定收益，降低了系统交互之间复杂交互逻辑的管理配置难度，同时超融合资源池化的设计对于业务系统资源的容灾容错也有得天独厚的优势，资源池的池间、池外的高可用、高可靠性相对其他架构体系增强不少。结合目前信息化的两个趋势：分布式架构和一体化架构，超融合解决方案在接下来的几年里也会有一番不小作为。
纵观近些年数据中心的发展，底层资源结构逐步统一成兼容并收的大平台，摆脱了各自为阵的信息孤岛。随着数据中心架构的逐步成熟，众多企业已经享受到了统一平台、大融合架构带来的收益，满足了业务系统迅猛发展的各种需求。然而，备份系统却没有像数据中心架构演进的如此积极、激进。面对庞大且重要的数据量， 企业必须使用更为行之有效的手段来为业务系统保驾护航。
从IDC近年来的调查与报告以及各大主流备份软件厂商的发展趋势，数据备份系统也逐步在一体化和分布式架构两种方向上演进。一部分备份产品借助分布式的架构，极大程度的扩展了并行性与高效性，通过简单的横向扩展就可以提高整体性能。随着万兆以太网的普及，在与分布式架构深度结合的备份软件解决方案中，异地容灾条件不再像传统备份解决方案那么苛刻。另一部分备份产品凭借一体化的优势简化备份架构，借助高效的重复数据删除技术，急剧缩减数据传输的时间、大幅降低网络间的压力、减少对业务系统性能的消耗。综合两种形态的发展趋势，虽然备份解决方案不似数据中心架构翻天覆地的变革，也逐步在向多形态、多架构、精简管理、便易维护等方向稳步发展。
1.2 变革与发展之中的数据保护
数据中心的架构逐渐丰富，传统的数据保护面临的挑战越来越严峻。传统数据保护解决方案首先面临的就是现今爆炸增长的数据量，增长速度快，巨量数据严重消耗容灾系统的性能；数据形态种类多，数据保护难度大；数据离散度高，集中备份的难度与日俱增。面对种种环境的变革与挑战，数据保护的技术手段发展并没有系统架构变革来得迅速、日新月异：在高时效、高要求的实时数据保护上仍是依靠高性能硬件的存储复制容灾方案为主；在归档、离线数据保护方面仍是依靠磁带等低廉存储介质实现；在多活、多中心业务系统与在线容错方面仍是传统多活解决方案或分布式集群技术实现。
随着一体化走进了各行各业的数据中心，边缘系统逐步由传统SNS（Server-Network-Storage）架构开始向其他系统架构过渡。在云和超融合解决方案的大力发展下，数据中心的部分业务系统也开始转向这两种新平台。超融合解决方案相对于传统SNS架构极大程度的减少了运维成本，同时使得管控更加集中化。对于超融合或分布式的解决方案中数据的分布处理，一部分解决方案强调Data Locality（数据本地性），计算资源和存储资源等数据尽可能统一，在同一物理资源上；一部分解决方案强调Data Ubiquity（数据流动性），虚拟化的计算资源和存储资源等数据尽可能打散，分布到不同物理资源上。在整体系统架构层面，云（私有云、公有云以及混合云）架构的普及逐步进入数据中心，但我们也注意到云的资源管控逻辑与业务系统的实际需求水土不符，以致于云在数据中心的普及速度稍逊于超融合解决方案。在数据中心架构变更缓慢的中小企业，SDS（Software Defined Storage）的解决方案更受决策者的青睐，利用低成本、高回报的SDS解决方案不仅底层资源管控可以高度统一，同时也为数据中心改造升级打下基础。
数据浪潮席卷而来的今天，容灾与备份技术没有翻天覆地的变化：在硬件（存储）容灾方面，集中式存储依旧利用快照、复制等保留数据副本、同步一致数据达到容灾的目的；分布式存储主要依靠快照和副本技术进行快速回滚、多数据副本满足容灾的需求；在SDS（Software Defined Storage）的解决方案中，借助虚拟化VVOL（Virtual Volume）的思想推出了基于资源池VVOL数据保护机制；云上的数据保护也没有更加全面、可靠，快照、副本、VVOL的数据安全保障略显单薄；BRS（Backup and Recovery System）逐步完善，但面对全新的挑战仍有诸多屏障：虽然BRS凭借高性能的硬件解决了一体化问题，推出了高规格的一体化产品，实现了大部分备份恢复的自动化操作，但对于自服务化的迫切需求仍然没有真正突破性进展。除此之外，对于云、超融合这类新型架构BRS没有深度结合，BRS架构仍然固守成规或者说没有迈出大胆的一步，没有真正与云和超融合开放性结构浑然一体，而仅仅是达到了及格线程度，未来还有许多路可走。
1.3 新时期下数据保护的期待
在数据中心高速发展的今时今日，我们认识到数据中心变革带来的数据保护的挑战，不仅仅是数据架构的多样性，而且无法充分深度满足日益增长的数据保护需求。在全面简化IT基础架构、一体化自动化的云驱动下，“数据保护即服务”的架构理念也随着数据中心的变迁而更加深刻。按照数据保护技术的发展趋势来看，以传统备份与恢复方式构建起来的数据保护机制在云计算时代逐渐捉襟见肘。传统方式的诸多弊端，如备份恢复步骤繁琐、环境条件苛刻、性能受限等，都将制约新时期下决策者们对数据保护的新需求。数据保护理应适应新技术的诞生、发展，在云计算发展的现在“多租户、云备份、云容灾”等趋势深入信息技术架构的蓝图。相对于传统投资昂贵、回报甚微的容灾方式，“数据保护即服务”的架构更能适应云时代，在不久的将来必将成为主流趋势。
随着互联网技术的迅速崛起，数据的存储方式、数据的量级等均发生了明显的变化：在相当长的一段时间里集中式存储以高效的物理性能承担了数据集中管控的绝大部分压力，在分布式理念普及后，利用低廉x86服务器分散了数据，一部分解决方案遵循Data Locality的原则发展分布式解决方案，整体上向分布式发展。这一点对于数据保护而言，利大于弊。在集中式存储上进行数据保护时，大量的IO操作对存储上层的业务系统性能都是一次次不小的压力考验，备份的高效率与业务系统的高时效一直是互斥博弈。而在分布式的架构体系统中，巨大的IO压力逐步被拆解至每一个计算节点上，即使网间数据流动压力会相应的增加，但在现今网络技术高速的发展下网间压力几乎不在话下。总体来看，云和其他分布式架构也在一定程度上解决了数据保护中压力集中爆发的难题。
面对现今爆炸式的数据增长，还有一项技术值得关注——重复数据删除技术。传统集中式备份恢复解决方案中，凭借重复数据删除技术获得了不小的收益，不仅存储备份数据需要的空间更小，而且源端重复数据删除技术也极大提高了备份系统的性能。在经过优化的重复数据删除解决方案中，结构化数据的整体备份恢复性能、备份存储利用效率往往能有数倍提升，非结构化数据的备份恢复效率大幅提升。除此之外，重复数据删除技术场景中历史数据的归档、复制、异地容灾需求也较传统解决方案更为智能和简便。在拥有重复数据删除技术设备之间进行数据拷贝复制，仅复制经过消重后、体量大幅缩减的元数据块，而非海量的原始数据。在此基础上，异地容灾保护也相对容易得多，不再需求大量的网络资源来支撑多个数据中心之间数据的复制同步，异地多活、多地容灾的门槛也相对降低些许。
结合数据中心的发展情况，未来给予数据保护的市场空间非常巨大。数据作为信息交互的媒介，是数据中心乃至企业的灵魂，数据的保护随着业务系统的发展、企业的成长会越来越重要。在过去的数年里，数不胜数的数据丢失事故也警醒着决策者们，越来越关注数据的价值发现与保护容灾，但在数据海的大环境下当前的数据保护意识仍需加强，数据保护的手段仍需提高。全面信息化的基础架构、逐步成熟化的业务系统、愈发严苛的服务等级需求，对未来的数据保护、容灾以及管理是一个巨大的挑战，也提出了一个更明确的要求——更开放、更透明、更广泛。
第二章 信息化基础资源架构的新发展
2.1 OpenStack
OpenStack解决方案作为近年各大供应商主推的架构方案之一，不得不说炙手可热。OpenStack作为一款云操作系统，其优秀的架构设计、有条不紊的管控分离、快速迭代的演进机制以及标准且开放的平台使得OpenStack在云计算领域突飞猛进。OpenStack逻辑结构如下图，主要组件包括Horizon（控制台）、Nova（计算）、Neutron（网络）、Swift（对象存储）、Cinder（块存储）、Glance（镜像）、Keystone（认证）、Ceilometer（计费）、Heat（编排）等。OpenStack逻辑结构组件虽然相对独立，每个功能组件均管控其相应的资源（如Nova负责计算池资源的管控与调度），但各个组件之间联系又非常紧密，每个组件功能均以REST API的形式提供给外部资源。逻辑结构的相对独立性决定了一个平台的发展，在保持平台底层架构基础上更大程度的发展其健壮性。组件与组件之间的标准接口通讯，使得其架构在演进过程中依旧规范。因此，OpenStack作为云计算主要新生力量之一，不仅生态完善更加完善、管控标准灵活，而且形成了云计算领域的标准规范。
OpenStack平台虽然优秀，但其巨大的体量也决定不管是开放的公有云还是封闭的私有云方案，海量的开发、优化、规范化的工作必不可少。作为开放性平台，OpenStack仅仅提供了标准化的平台解决方案。从标准化的解决方案到实际应用落地，绝不是一蹴而就。从目前国内各大主流云计算生态的发展趋势来看，作为互联网行业巨头阿里在云计算（公有云）从平台模型到实际落地再到初步优化投入使用的成本就已达数百亿人民币。云计算，并不容易，这份不容易不仅仅是需要昂贵的物力成本，更是需要大量的核心技术人力去支撑云平台成功落地。
OpenStack平台，是一款优秀的产品解决方案……理念。开源产品最大的痛点就是实际投入使用困难重重。一个优秀的理念，从理论到实践，不仅仅需要时间的积累，更需要实力的积蓄，洞察企业系统架构，联系实际发展需求，综合未来发展趋势，将理念一步一步雕琢后才能投入实践之中。OpenStack，便是如此，从业务需求、应用类型到整个交互逻辑适配OpenStack，开发维护工作可想而知。因此，在当前信息化的变革之中，决心跻身于OpenStack的企业必然不少，真正能有多少一番作为的领导者还需时间去检验，不管结果如何，都会是一次精彩的尝试与挑战。
由于OpenStack与虚拟化技术结合的时间较短，技术、接口模型尚不完善，因此在近几年的OpenStack解决方案中，还未遇到与主流备份软件深度兼容的案例出现。OpenStack是一种更开放的分布式结构思想，而主流数据保护解决方案还是依附于传统的SNS（Server-Network-Storage）架构缓慢发展。两种截然不同的架构逻辑注定给两种技术的深度兼容带来不少困扰。目前在OpenStack平台上，对于数据的保护更多的是依赖快照进行，对于数据的高可靠性、高可用性通过集群、副本技术即可满足。若是有数据进行历史保留，主流的备份软件也可通过Server-Client方式完成备份任务。云上的数据保护勉强过关，作为长远的发展，备份与恢复要和云计算契合，实现“数据保护即服务”的架构理念必不可少，而这一点还有很多路要走。
2.2 HCI
超融合架构（Hyper Converged Infrastructure）解决方案作为近两年的新兴力量，在信息化删繁就简的过渡时期取得了不小的成功。超融合架构的迅速崛起，得益于基础硬件资源的高速发展和高效的性能，同时又赢得了分布式存储的一票，天时地利人和应有尽有。对于国内的超融合现状巨大的市场空间无疑是众多厂商跃跃欲试的动力；经过几年角逐，大部分超融合供应商均取得了不错的业绩增长；不少国产解决方案提供商纷纷以良好的开端业绩加入超融合市场的龙争虎斗之中。
超融合解决方案规划了一个极度精简的信息化架构，相比于传统SNS（Server-Network-Storage）架构，超融合产品在硬件资源的部署、运维、管控上占有绝对优势。计算、存储、网络融合为一体，管控平台统一，对数据中心运维人员提供了非常优厚的便利，从繁杂的硬件资源管理维护工作中解脱出来。简约的产品必定面对不简约的问题，超融合解决方案面对的首要问题就是数据安全与保护。首先是超融合产品与虚拟化基础的结合问题，新方案的初期多重技术的兼容尚未成熟，主流的KVM虚拟化技术在各大超融合平台上火力尚未全开，远远没有发挥KVM技术的绝大部分虚拟化优势。其次超融合产品初期没有与备份恢复解决方案提供商形成良好互动，很主要的一个原因是市场角逐者各自为阵造成标准不统一，适配困难。另一方面，超融合的集群（异地）容灾和多中心解决方案对资源要求仍旧过于苛刻，特别是对网络的需求。即使物理资源投入充足，超融合容灾方案所达到的RPO/RTO与其投入成本相比也未尽人意。最后超融合产品的技术整体成熟度还比较低，不仅仅是数据保护的机制无法满足企业快速发展的需要，而且相对于传统虚拟化技术在产品功能性上还很欠缺。
2.3 大数据处理平台
在信息化发展的今天，数据蓬勃发展，数据量级与日俱增，但数据的价值越来越被忽视。在2016年前后，“大数据时代”的理念走上舞台，通过的大数据的分析，不仅提升了创新价值的认知，更发掘出了数据潜在的底蕴价值。不少数据中心看到大数据时代的曙光，纷纷部署了以“Hdaoop”为代表的分布式大数据处理平台。
在分布式大数据处理架构诞生之初，不少企业对其备份恢复等数据保护手段不太重视，即使是主流的数据保护解决方案提供商也淡然视之。一方面是分布式架构与集中式架构的兼容、对接难度大，另一方面是在分布式架构上数据自身就拥有高效的防护机制，无论是历史留存还是大数据运算结果集转存都能够胜任。但以长远的眼光去审视大数据管理，随着数据体量剧增、维度宽泛，统一的数据管控平台必将占据领导地位。虽然大数据的样本采样能够容忍一定程度的数据个体失准、分布式平台具有高效的容错技术，但依旧无法防止逻辑给大数据平台带来的影响。因此，在数据管控平台的规划日程中数据保护、归档等功能越来越重要。
目前国内Hadoop大数据平台绝大部分都是以定制化研发为驱动，其架构、规范各不相同，所以依靠BRS解决方案提供商来适配数据管控功能阻力重重，与大数据平台一体化的数据管理平台很大可能也是自主研发解决。从几例大型Hadoop大数据平台项目来看，数据的备份恢复与归档几乎都是通过Hadoop的特性稍加拓展来实现，还未形成方案规范。
第3章 BRS技术发展
3.1 BRS技术发展之存储容灾
在本篇文章中，对于BRS技术的发展很少提及基于集中式存储的复制、容灾方案。从当前的数据中心形态发展上，未来的数据中心必定向一个更开发、多形态并存的组织架构演进，完全集中式的基础架构很难再现。因此基于集中式存储的复制、容灾方案在未来的发展上，应用的方方面面将会越来越窄，实际落地的困难也越来越多，更主要的是带来的收益将越来越小。
诚然，基于集中式存储的复制、容灾方案确实是一个一劳永逸、十分契合数据中心对容灾系统各项期待的综合性方案，但随着数据中心体量的逐步提升，数据中心形态面对大数据的侵袭必将调整姿态，而在这一变一改之中，集中式存储的优势就慢慢殆尽。集中式与分布式，是两种不同的系统架构形态，基于集中式存储的复制、容灾方案对于集中式的架构优势显而易见，但对于分布式架构的适用性也无需言谕。对于分布式的架构形态，更多的是希望能从集中式的容灾上集众之所长、打造一套与之媲美的整体解决方案。
3.2 BRS技术发展之备份恢复系统
在过去的几年里，相对数据中心架构体系的变革，BRS的技术发展确实缓慢。无论是容灾还是备份恢复归档等方面都没有取得质的飞跃。数据中心容灾方面，通过存储及其相关解决方案实现的容灾已经高度同化，虽然解决方案多样但大道疏同。相对于传统集中式数据存储，分布式存储和对象存储迎来新纪元，逐步在市场上铺开。数据中心备份恢复以及归档系统上，备份存储介质更加广泛，不仅仅是局限于磁盘、磁带，光盘、云存储等也加入到了行列之中。随着隧道磁电阻TMR（Tunneling MagnetoResistance）技术与LTO（Linear Tape Open）线性磁带开放协议技术突破与发展，磁带存储的优势会越来越大。
虽然备份恢复系统的基础资源发展进步不小，但是在信息化基础建设的大浪潮下，这些技术的突破还没有信息体量的增长迅速。在短短的几年间，信息数据体量由原来TB级已经迈进了PB级别，在不久的将来绝大部分前瞻企业可能都会提升到ZB级别。信息系统前端的数据量级成线性指数般增长，然而备份恢复系统的性能（尤其是后端备份存储的性能）却只是小幅度提升，机械磁盘、磁带、光盘这类传统存储介质的性能发展与突破也没有骤然攀升。最近两年闪存的技术逐年更新演进，但对于绝大部分企业来说，闪存产品用在业务系统上已是一笔不小的开支，倘若数据量巨大的备份恢复系统也如此耗资耗力，其成本带来的必然是一份难以承受的压力。在备份恢复系统还没有完全适配新兴架构的前提下，如何更高效的提供备份恢复系统的性能？无法从后端存储介质性能上满足企业数据发展提出的数据保护需要，那就从前端上将需要保护的体量经过处理大幅缩减数据体积，高效处理有效数据，因而重复数据删除技术便有了用武之地。
近几年CPU、内存、硬盘、闪存等制造工艺的发展，重复数据删除（以下简称“重删”）技术突飞猛进。对于备份恢复系统而言，重删技术是一项核心技术，面对大数据的侵袭，重删技术不仅能够有效减少系统的数据传输负载，还能大幅提供备份存储的利用率。按照不同的分类标准，重删技术又有不同的定义：按照重删基准分类可以分为基于物理硬件设备的重删和基于纯软件的重删，基于物理硬件设备的重删一般依靠物理硬件的CPU、内存等资源进行计算、比对后进行重删，基于纯软件的重删一般单纯的依靠高效算法对数据进行去重处理；按照重删方式或目标可以分为源端在线重删和目标端线下重删。在线和线下主要强调数据进行重删过程发生的时间，数据备份时进行重删操作称为在线重删，数据备份完成后进行重删称为线下重删，一般情况下在线重删比线下重删对整体性能最友好。源端重删和目标端重删主要强调数据进行重删过程发生的地点，在数据源端进行重删称为源端消重，在备份存储上进行重删称为目标端消重。机械磁盘、磁带、光盘这类传统存储介质的性能虽然没有突破性进展，但CPU、内存的性能相对过去的境况却有了相当的进步，计算处理能力提升明显，在重删技术领域，目前业界较为主流的是基于CPU、内存强大性能直接快速运算来进行消重，数据在CPU和内存间的交互多，很少在磁盘上流动，因此重删效率和重删性能非常客观。其次是各大厂商具有重删技术的虚拟磁带库产品。具有重删技术的虚拟磁带库在数据落到磁盘上开始消重，其性能主要取决于磁盘存储整体性能与节点的计算能力。最后则是各大厂商的软件消重引擎，通过安装客户端软件或插件来实现数据消重，经过长久的发展，纯软件的消重也获得不错的性能表现。
3.3 核心技术详解
3.3.1 重复数据删除技术简介
随着大数据的普及，数据的潜在价值越来越受到决策者的关注，在接下来的若干年里数据中心存储的数据量级将会出现质地飞跃。对于备份容灾系统而言，面对的大数据保护的压力也大幅提升，在当前信息化发展境况下，除了改良物理设备（如磁盘、磁带、光盘、控制器等）的综合性能，剩下有效措施就是想方设法提高对数据的处理能力。因此，在保护的数据量级逐渐提升的情况，重复数据删除技术将扮演越来越重要的角色。
此前我们简单介绍了重复数据删除技术，接下来深入了解重复数据删除技术的机制。重复数据删除技术的工作原理和杀毒技术的工作原理类似：杀毒软件主要通过读取文件、计算特征码、对比特征码、智能判断这四大步骤来判断文件是病毒源还是正常文件， 重复数据删除技术也采用了类似的过程来实现数据块重删功能。从这四个处理过程来看，重复数据删除技术的性能主要取决于读取文件、计算特征码、对比特征码这三个步骤的速度。在磁盘存储上频繁读写文件数据再计算特征值的速度，明显没有将文件数据读到内存中再计算特征值的速度快，尤其是面对持续大数据量冲击两种方式的差距更加一目了然。因此重删过程尽量保持在CPU和内存这类高速设备中、减少数据落盘能够显著提升重删性能，这也是此类产品系列在重复数据删除领域独占鳌头的主要原因。
3.3.2 重复数据删除技术原理解析
重复数据删除技术是一门相当复杂的技术，尤其是重删过程中的切片算法，切片算法的优劣极大程度的决定了重复数据删除技术实现的整体性能。在重复数据删除产品领域，目前较为优异的切片处理为基于CPU和内存的4-12kb可变长动态切片处理技术（精度小、切片长度可变、动态处理）。接下来通过一款该产品的工作原理图来聊聊基于CPU和内存的重复数据删除产品是如何实现数据重删功能。
此产品支持全局重复数据删除技术，即可以跨越多个Controller进行数据重删（入门级产品仅配置一个Controller，中高端产品才有多个Controller配置）。重复数据删除过程主要覆盖两个部分：客户端的重复数据删除区和产品端全局重删系统。其中Chunking（第一次）、Routing、Chunking（第二次）以及部分Filting过程主要发生在客户端的重复数据删除区里，另一部分Filting及DataSave过程发生在全局重删系统。在整个消重过程中，除了DataSave部分将消重数据块落盘存储，其他部分均在CPU与内存之间完成交互，因此相对于其他重复数据删除产品在整体性能几乎没有瓶颈。此产品在执行重复数据删除过程中，由于是CPU与内存承担主要任务高而磁盘阵列的IO较低，如果此时向其他设备进行复制克隆任务，复制克隆任务整体效率将显著降低。
接下来我们逐步分析在全局重复数据删除过程中每一个步骤及其功能：
Initializtion
在执行重复数据删除任务前，客户端合与此产品控制器进行通讯交互，分布式块处理进程DSP（Deduplicated Segment Process）进入初始化，客户端会开辟一部分内存空间用于缓存，同时分配一小部分硬盘空间用于暂存Hash表，Controller将加载对应Hash表为重删过程做准备。在一切准备条件完成后，重复数据删除系统即接收数据流。
Chunking（第一次）
当数据流进入客户端的重复数据删除区， 分布式块处理进程DSP会根据数据流特征进行切片处理，数据流会被切片为平均长度为1 MB的数据块。首次Chunking是基于数据流CONTENT PATTERNS并不是基于BLOCK或FILE，在此之后大型数据流会被分解为数据片段，减轻重删压力。
Routing
经过Chunking后的数据片段，分布式块处理进程DSP再根据数据片段内数据结构进行分配映射，确保类似的数据块均被映射相同处理进程上并和对应的Controller联合进行重复数据删除处理。Routing之后，数据片段分门别类，相似的数据片段尽量保持在相同的进程及Controller上处理，大幅提高了处理效率。
Chunking（第二次）
分布式块处理进程DSP将映射过来的数据片段再次进行切片处理，所有的数据片段将基于4-12 kb粒度进行可变长动态切片。可变长动态分片技术是重复数据删除的核心，分片最小精度为4kb，最大精度是12kb，切片精度越小获得重复数据片段的几率越大，重复数据删除效率越高。经过Chunking- Routing- Chunking后的数据片段已经充分处理，相似度极高，下一步即将开始Filting。
Filting
在客户端上分布式块处理进程DSP开始处理经过两次Chunking的数据片段，为所有数据片段计算指纹ID（或块ID）。每一片指纹ID通过网络传输至Controller处理进程上，进程开始将此指纹ID与产品终端上已存储的指纹ID集进行对比，如果指纹ID集内已存在，则原指纹ID及其所对应的数据片段将被标记、指针处理后抛弃；若指纹ID为新，则原指纹ID将在产品终端上存储的指纹ID集更新，其所对应的数据片段就通过LZ、GZ、Gzfast等压缩技术准备存储，所有相关的元数据经过处理准备存储。
DataSave
全局重删系统将新的数据片段（经过压缩后）及其相关指纹ID、元数据进行存储，同步更新所有日志等。
3.3.3 重复数据删除的期望收益
相比于基于纯软件的重复数据删除技术或目标端线下重删技术，分布式块处理进程DSP带来了诸多收益：
1，更高效的CPU和内存利用率
在CPU和内存间进行交互提高了重复数据删除整体效率，减少了其他软硬件因素的制约。
2，大幅提高网络带宽利用率，减少网络资源消耗
相对于其他重复数据删除技术实现，客户端与产品之间网络仅传输指纹ID、非重复数据片段等，网络占用低，不会形成大流量网络冲击影响业务性能。
3，任务重启后耗时短
数据保护任务再次重启时，未变更的数据片段仅进行计算对比后就被抛弃，网络间不进行传输，耗时短，若重复命中率高，速度会更进一步提高；已变更的数据片段经过重删过程后即被压缩存储。重启任务时整体效率提升显著。
数据保护任务失败时，重启该任务后已经成功处理的数据仅在DSP内进行短时间的计算对比后抛弃，数据不会传输到产品内部。不仅缩短了重启任务耗时，还减少了网络负载提高了任务期间整体吞吐效率。
4，更平衡的工作负载
相对于其他重复数据删除产品的实现，Controller和重复数据删除系统将任务的负载压力更科学的平衡在客户端与重复数据删除系统之间，提高了多个物理设备的整体利用率。
3.3.4 重复数据删除的实际运行效率
此前曾针对某款基于CPU和内存的重复数据删除产品进行过一次性能测试，本次测试具体环境配置如下：
备份任务运行稳定后，产品终端负载情况：
备份任务运行稳定后，FTP文件服务器负载情况：
CPU：
内存：
磁盘：
网络：
第一次重复数据删除备份任务整个备份过程约42分钟，备份数据量约403 GB，平均备份速度167 MB/S。产品终端实际写入数据约为77 GB，全局重复数据删除比为5.2x。
从以上图例，我们可以清晰的看到：进入备份后客户端（FTP文件服务器）CPU使用率逐渐提升，备份完成后CPU使用率回降，在整个备份过程中CPU（1 vCPU）高峰值基本维持在75%左右，大部分时间使用率低于75%，对于1 vCPU的虚拟机而言已经是不错的成绩。内存方面，备份占用的内存大小最高没有超过300MB，控制得不错。磁盘IO方面，全程平均读速度约110 MB/S（最高230 MB/S）。网络使用情况，大部分速率维持在5 MB/S以下，高峰值约为20 MB/S，全程平均值为1.3 MB/S。产品终端在截取的200s备份区间内，CPU一直维持在13%左右的使用率，磁盘使用率持续在10MB/S以下，网络负载在1 MB/S左右，BOOST逻辑速度前80s约220 MB/S，后120s开始大幅抖动，这也反映出非结构型数据备份的特点。
本次测试也明显的展示了源端重复数据删除的特点，也突出了这类基于CPU和内存实现重删技术的设备的优缺点。在备份过程中，客户端上CPU和内存均会有部分负载，磁盘IO持续高载，但网络压力大幅减少，仅1 MB/S平均负载。产品终端CPU压力明显上升，维持在13%左右，磁盘压力非常小，一直维持在10 MB/S以下，网络负载微乎其微 1MB/S左右。对于网络环境较差的业务场景，重复数据删除备份是一种优异的备份方式，不仅备份速度优异，网络压力也非常小。然而也注意到在重复数据删除存储这边，CPU、内存压力一直存在，若多备份任务叠加，其整体负载几乎线性递增。倘若此时还有复制或克隆任务，其性能则会大打折扣。
第4章 备份恢复系统的考量
4.1 备份恢复系统现状及问题
备份恢复系统，是一门既简单又复杂的学问，简单之处在于只有几个基础软件配置，复杂之处在于往往配置完成之后性能效果不尽如人意。在我们的印象里，备份恢复系统往往就是一路NEXT安装软件，然后填几个参数能搞定配置，备份恢复任务跑起来就大功告成。但很多时候，我们都在抱怨备份恢复任务为什么这么慢？硬件配置都达标了，为什么还跑不出来应有的性能？为什么这个不能备份恢复？……
也许备份恢复系统部署之后，一年之中除了常规数据验证、校验外，几乎用不到几次恢复。可真正用上备份恢复系统的时候，很可能就不是常规数据恢复验证这种简单的事。数据中心建设之初，可能由于规划、费用等诸多限制，备份恢复系统没有那么尽善尽美的物理条件，很多前期工作就草草了事。再加上国内专精于备份恢复系统的集成商少之又少，绝大部分都是默认安装、默认配置、简单测试没问题就进入验收，有的甚至连软件的默认安装目录都懒得改。看过了不少公司的备份恢复系统，不得不说备份恢复系统是一个相当重要的数据中心组成部分，随着数据量级越来越大，其重要作用越来越明显。当常规数据保护手段失效后，备份恢复系统就是最后一根救命稻草。
说回备份恢复系统的优化工作，从备份策略表到数据存储策略，从各类应用的配置到参数调整，从单个任务的效率到全局备份任务协调，随地随处都蕴涵着值得细细斟酌的价值。对于备份任务，有线性有并行；对于并行，有流复用有流串行；对于备份存储，有物理驱动器串行并行优化，有虚拟驱动器的块优化……对于没有从事BRS这块的技术人员来说，这些概念很少了解，它们既不像中间件数据库那么普及，也不像服务器存储那样通俗，不仅连带着各式各样的借口与备份恢复系统产品还需要因地制宜的调整。总得来说，备份恢复系统是一项非常小众但异常重要的系统，虽然简单但仍有许多值得研究的地方。
4.2 备份恢复系统的考量
4.2.1 架构规划
在大型备份恢复系统中，BRS架构规划是相当重要的一部分。随着备份恢复系统的体量越来越大，更改架构的难度和可行性越来越低，除去备份恢复系统上的配置变更限制，更多的是实际环境带来的重重限制让架构变更难上加难。后期重新进行备份恢复系统的架构变更，牵一发而动全身，因此初期做好备份恢复系统架构规划是整个规划建设中的重中之重。
备份恢复系统规划的几个原则：
1，管控分离
备份恢复系统中的MASTER SERVER不承担或尽量少承担备份恢复任务。MASTER SERVER是整个备份系统的核心，其性能效率直接影响所有备份恢复等任务调度。所有的备份恢复任务有MEDIA NODE或者STORAGE NODE承载，集中数据和任务的管控能力，更明确了任务压力路径的规划。
2，流量分层
将业务流量和备份恢复系统流量分开，若做不到物理隔离（使用不同物理卡进行任务），至少也要做到时段上隔离；减少网络之间的串流，数据流量坚持从当前网络的MEDIA NODE或者STORAGE NODE写入到备份存储；分离备份恢复系统管控流量，当从同一个网络层面进行大数据量备份时备份流量的冲击会明显影响 备份恢复系统的管控流量，造成备份恢复通讯假死等诸多异常情况。
3，流量隔离
每个网络段或业务段间的备份流量隔离，当前网络段或业务段的流量上向上汇总至MEDIA NODE或者STORAGE NODE上，或直接写入备份存储。通过流量的分层和隔离在垂直向和横向上规划出每个区段流量的走向，禁止跨网络跨业务端的流量出现，同时将大小流量束平衡，避免各节点上压力出现严重倾斜。
4，重复数据删除
随着数据中心内业务数据量的增长，重复数据删除技术越来越凸显出优势，尤其是面对网络环境较差的数据保护需求。根据实际条件选择重复数据删除技术，尤其是源端重复数据删除，能够大幅减少网络负载，同时提高备份恢复任务的并行性，但同时也需要注意客户端上性能压力。重复数据删除技术适用于虚拟化（如虚拟机整机备份）、变更较少的数据集（如文件服务器）、大型结构化数据集（如数据库等）等各类数据保护。
5，备份设备池化
备份设备池化有助于提供设备综合使用率。虽然各备份恢复系统对于备份设备的控制逻辑并不支持池化的配置，但它们能够根据备份设备繁忙程度去智能分配，因此以池化的概念去管理分配设备依旧可以让不支持池化的备份恢复系统灵活使用。在一个备份设备池内，池内所有设备仅分配这一类型的备份任务，让备份软件决定分配哪一个设备，如果考虑设备争用问题，可预留20%的富余设备资源。
6，任务流串并行
在实际运用中，任务流的串并行能够显著提供整体运行效率。针对备份流量小的备份任务，可以将备份流串行，并发进行多个小流量的备份任务并将这些流量通过一个或几个备份设备写入备份存储，在提高效率的同时提高设备使用率。当备份任务流量较大时，可以设置动态流将大数据流分解为几个并行流通过备份池分配不同设备写入备份存储。
4.2.2 参数调优
备份恢复系统的参数调优是一个非常有难度的挑战，不仅仅是根据应用类别挑选不同的调整原则，而且还要根据实际业务配置调整具体参数配置。
下面以通过某款重复数据删除产品备份Oracle数据库的配置，为备份任务的调优提供一点思路。
某公司拥有一套 7 TB Oracle四节点RAC数据库，通过某源端消重备份，原RMAN全备份脚本内DATAFILE备份部分CHANNEL为6，FILEPERSET为50，MULTIPLEX为True，未设置备份BLOCKSIZE，ARCHIVELOG部分CHANNEL为2，FILEPERSET为30。整个备份过程约3.2小时，备份数据量约7 TB，平均备份速度约650MB/S。
优化过程如下：
1．DATAFILE备份部分
数据文件备份部分是整个优化过程的核心，数据文件备份速率极大影响整个全备份的速率。通过重复数据删除技术的原理解析，我们知道数据越单一经过相同的切片原则、以相同的精度切片后，重复命中率越高。因此在考虑消重效率时，控制数据杂糅度至关重要。在原全备份脚本数据文件备份部分中，FILEPERSET为50，大幅降低了每个BACKUP PIECE的数据纯度，生成的BACKUP PIECE会由50个DATAFILE内的数据随机组成，不利于重删。如果降低FILEPERSET数量，则需要进一步提高CHANNEL数量，从而提高整体备份效率。同时MULTIPLEX为True，并行备份开启不利用提高数据片的单一纯度。在未设置备份BLOCKSIZE时，备份软件会以默认的BLOCKSIZE读取每个BACKUP PIECE并以这个精度将数据传输至备份设备，结合实际应用场景适当提高BLOCKSIZE，能够优化数据传输性能。对于大数据量级备份，BLOCKSIZE建议1 MB以上。
综合以上分析，根据以下三个原则来进行优化：
调整CHANNEL和FILEPERSET来提高单一批次BACKUP PIECE的备份性能。
FILEPERSET尽量保持为1，即BACKUP PIECE只有1个DATAFILE。
根据实际备份实际性能调整BLOCKSIZE值，BLOCKSIZE值只能调大、不能调小。
第一次调整CHANNEL为10（数据文件为270个），FILEPERSET为1，MULTIPLEX为False，BLOCKSIZE为1 MB。初步调整后，备份平均速度略有提升，约700+ MB/S。
后续根据实际备份情况进行调整，调整CHANNEL为20，FILEPERSET为1，MULTIPLEX为False，BLOCKSIZE为2 MB。最终调整后备份平均速度略有提升，约850+ MB/S。
2．ARCHIVELOG备份部分
归档文件备份部分是整个重复数据删除效率的核心，根据实际维护经验可以知道，归档文件的重删效率是最低的，重删比几乎接近0，归档文件基本上只会被“压缩”处理。这是文件形态及内容决定其不适用于重复数据删除，而不是参数优化等问题。因此将归档文件备份的备份存储改到已有的物理磁带库上，避免浪费重复数据删除设备上的空间、降低整体重删效率。
根据归档文件产生的速率（1分钟左右产生一个2 GB归档）与归档保留策略要求，归档备份策略调整为每2小时进行一次，CHANNEL为4，FILEPERSET为20，MULTIPLEX为False，BLOCKSIZE为2 MB，每次归档备份完成后删除此时间点6小时前的归档文件。
4.2.3 系统优化
相比于参数调优，系统优化更为细致。整个备份恢复系统应用的实际场景形态各异，不管是业务系统规模、特征还是对数据保护的重视程度，各不相同。因此在备份恢复系统的优化上，不仅仅是依照最佳实践手册去调整整个系统的配置，更是以实际运维经验为导向去深入业务场景，以实际业务特征去逐个优化系统的各项指标、参数等。
以下分享几个维护心得，供各位参考：
1，备份策略表
每个系统管理者对备份恢复系统的管理角度各不相同，有的希望从业务视角明细每个系统的数据保护如何进行，有的希望从备份恢复系统视角知悉每个任务是如何保护业务系统数据……但不管从哪个视角去管理备份恢复系统，必须具备一份明细的备份策略表，这也是备份恢复系统优化的基础。如果重视业务，则以业务系统为层级区分，文件系统备份如何进行，有哪些备份恢复任务在这个层级内，什么时间备份，间隔多久，备份到哪儿；数据库系统备份如何进行，备份组、备份策略如何安排，数据文件和归档文件各自如何管理；中间件备份如何进行，备份集的内容是业务系统的什么数据，备份策略如何安排等。如果重视备份恢复系统，则在每个备份恢复管理组上标注对应的业务系统，方便备份恢复系统与业务系统对应。
2，备份设备池
对于精细化备份恢复控制，建议备份设备一对一管控，将备份链路固定，避免设备争用、链路混乱等问题；对于一般性备份恢复控制，建议备份设备池化，虽然许多数据保护软件厂商的产品并不支持池化的配置，但它们能够根据备份设备繁忙程度去智能分配，因此以池化的概念去管理分配设备依旧可以让不支持池化的备份恢复系统灵活使用。不管是何种管理方式，预留20%的设备资源作为紧急资源，防止设备意外损坏的不时之需。
3，熟悉业务系统
作为一名备份恢复系统的管理者，没有任何义务去了解并熟悉业务系统，但事实往往并不是这样。只有更熟悉了业务系统后，慢慢了解业务系统的特点、数据流量的特征，才能动手更有针对性的去优化整个备份恢复系统。对于业务系统最基本的特征都不熟悉，又以何依据为指导去优化备份恢复系统呢？最佳实践手册里可不会告诉你，这个业务场景下备份配置怎么调整、那个业务场景下备份配置如何优化。业务系统场景的真实表现，是备份恢复调优最直观的调优依据。
参考文章：
《2018预测：归档、闪存、磁带、云存储、对象、光盘何处去》 中文译文
点击阅读原文可下载原文档
觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
下载 twt 社区客户端 APP
长按识别二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场